home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / bgp / bgp-minutes-90may.txt < prev    next >
Text File  |  1993-02-17  |  3KB  |  79 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by Guy Almes/ Rice
  6.  
  7. MINUTES
  8.  
  9.  
  10.   1. Guy Almes and Yakov Rekhter led a review of progress to date,
  11.      including the conditional acceptance of the BGP Protocol document
  12.      as a Proposed Internet Standard.  (By mid-May, the BGP Protocol
  13.      document was approved by the IESG and forwarded to the IAB for
  14.      approval as a Proposed Internet Standard.  Both the BGP Protocol
  15.      and the BGP Usage documents will soon be published.)  Changes to
  16.      the protocol since the Florida State meeting were discussed.
  17.   2. Yakov Rekhter led a discussion of BGP stability.  It is possible to
  18.      configure a pair of neighboring ASes with incompatible routing
  19.      policies such that an oscillation sets in.  Yakov sketched the
  20.      problem in detail and showed how the oscillation could be
  21.      automatically detected.
  22.   3. Steve Willis led a discussion of a proposed MIB for BGP. This
  23.      discussion resulted both in a better proposed MIB and a deeper
  24.      understanding within the group of a number of BGP issues.  A key
  25.      issue was whether the BGP MIB should reflect the BGP information
  26.      received from neighbors, actually used locally, or advertised to
  27.      neighbors.  Steve will follow up with an Internet Draft describing
  28.      the MIB.
  29.   4. Guy Almes led a discussion of the use of BGP in monitoring the
  30.      health of global Inter-AS routing.  In the course of the
  31.      discussion, the implications of External vs Internal BGP, even in
  32.      the case of the monitoring station not being involved in routing,
  33.      were shown to be important.  The use of BGP for monitoring will
  34.      allow a number of monitoring applications that would be totally
  35.      impractical using only SNMP.
  36.   5. Guy Almes led a discussion of authentication.  Consultation with
  37.      members of the Security Area led to an agreement that a 16-byte
  38.      Marker field per message would allow detection of spoofing.
  39.      Prevention of spoofing seems to be beyond the ability of any
  40.      application layered over available implementations of TCP. The
  41.      presence of this 16-byte field, together with our provision of
  42.      multiple authentication schemes, will allow very strong
  43.      authentication.  Having agreed on the need for supporting strong
  44.      authentication and having modified the protocol to support it, we
  45.      agreed that our needs in the near-term future were not great.
  46.  
  47.  
  48.  
  49.                                    1
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. ATTENDEES
  57.     L. Allyson Brown          allyson@umd5.umd.edu
  58.     Guy Almes                 almes@rice.edu
  59.     Isidro Castineyra         isidro@bbn.com
  60.     Steve Crumb               scrumb@mot.com
  61.     Robert Enger              enger@sccgate.scc.com
  62.     Dino Farinacci            dino@esd.3com.com
  63.     Dennis Ferguson           dennis@gw.ccie.utoronto.ca
  64.     Jeffrey Honig             jch@tcgould.tn.cornell.edu
  65.     Wendy Huntoon             huntoon@a.pse.edu
  66.     Peter Kirstein            kirstein@cs.ucl.ac.uk
  67.     Alex Koifman              akoifman@bbn.com
  68.     Kanchez Loa               loa@sps.mot.com
  69.     Yoni Malachi              yoni@cs.stanford.edu
  70.     C. Philip Wood            cpw@lanl.gov
  71.     Yakov Rekhter             yakov@ibm.com
  72.     Mike StJohns              stjohns@umds.umd.edu
  73.     Steve Storch              sstorch@bbn.com
  74.     Steven Willis             swillis@wellfleet.com
  75.  
  76.  
  77.  
  78.                               2
  79.